[BE] 쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 변경 + 리팩터링(#613) #617
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Test Results 55 files 55 suites 8s ⏱️ Results for commit 34540ff. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
로직 커밋 바로가기 해줘서 고마워요 ㅎ.ㅎ
File Change 는 많았지만 reader, writer 분리와 dto 네이밍 수정때문인지라 잘 되었는지 확인을 주로 했습니다.
고생 많았어요!
질문만 코멘트로 달고 로직에 문제 없는 것 같아 approve 드립니당!
아래는 P2 에 대한 생각과 추가 질문입니다.
질문
서비스-도메인 계층에서의 DTO 네이밍을 바꾼건 좋은 관점인 것 같아요.
Input, Output 이라는 네이밍을 사용하게 된 이유가 궁금해요.
콘솔 혹은 DB와 소통할 거라고 오해할 수 있는 네이밍으로도 느껴지긴 하네요.
DTO 변환 책임에 대해서
결국 Mapper 라는, 레이어와 레이어를 이어주는 친구가 생겨야 하는건 어쩔수 없겠지만
Mapper 로 DTO 간 의존성을 끊는 것이 좋은 것 같아요.
DTO 끼리 의존성이 생겼을 때, 기능이 확장됨에 따라 DTO 가 꼭 일대일로만 의존성이 생기지 않을 것 같아 걱정이 되는 것 같아요.
한 DTO 에서 여러 DTO 로 변환하게 되면 유지보수 관점에서 더 불편해 질거라는 생각이 들어요.
그렇다고 Service 계층에서 직접 DTO 를 변환하는건,,,
저는 Mapper 사용이 위 방법중엔 괜찮은 선택인 것 같습니다.
Mapper 를 분석하면서 DTO 의 변환을 통해 로직을 유추할 수 있는 것도 장점이 될 수 있을 것 같고요.
| private UserFeedbackResponse getUserFeedbackResponse(Map<Long, List<FeedbackResponse>> developFeedback, Map<Long, List<FeedbackResponse>> socialFeedback) { | ||
| List<Room> rooms = roomRepository.findAllById( | ||
| extractDistinctKeyStreams(developFeedback, socialFeedback).toList()); | ||
| private UserFeedbackResponse getUserFeedbackResponse(Map<Long, List<FeedbackResponse>> developFeedback, Map<Long, List<FeedbackResponse>> socialFeedback, Predicate<Room> predicate) { |
There was a problem hiding this comment.
predicate 가 이름을 가지면 좋겠는데, 적절한 이름이 떠오르지 않네요..
| extractDistinctKeyStreams(developFeedback, socialFeedback).toList()); | ||
| private UserFeedbackResponse getUserFeedbackResponse(Map<Long, List<FeedbackResponse>> developFeedback, Map<Long, List<FeedbackResponse>> socialFeedback, Predicate<Room> predicate) { | ||
| List<Long> roomIds = extractDistinctKeyStreams(developFeedback, socialFeedback).toList(); | ||
| List<Room> rooms = roomRepository.findAllById(roomIds); |
There was a problem hiding this comment.
findAllByIds 와 findAllById 가 동작이 같은가요? 궁금해서 질문 남깁니다.
There was a problem hiding this comment.
JPA에서는 findAllById가 표준 메서드로 제공되지만, findAllByIds는 없습니다.
findAllById는 기본적으로 여러 개의 ID를 인자로 받아서 해당 ID들에 해당하는 엔티티들을 모두 조회합니다.
기본적으로 제공되는 것은 findAllById이며, 두 메서드의 동작은 같지 않습니다~
findAllByIds를 사용하려면 직접 메서드를 정의해야겠네요!
|
|
||
| assertThat(response.feedbacks()).hasSize(2); | ||
| assertThat(response.feedbacks().get(0).developFeedback()).hasSize(1); | ||
| assertThat(response.feedbacks().get(0).socialFeedback()).hasSize(1); | ||
| assertThat(response.feedbacks().get(1).developFeedback()).hasSize(1); | ||
| } | ||
|
|
||
| @Test | ||
| @DisplayName("자신이 받은 피드백을 받을 때는 닫혀있는 방에서만 받는다.") |
There was a problem hiding this comment.
"자신이 받은 피드백은 닫혀있는 방에서 작성된 피드백만 확인할 수 있다" 와 같은 수정은 어떠신가요?
There was a problem hiding this comment.
Reader와 Writer의 역할을 분리하면서 RequestDto와 ResponseDto를 어디까지 전달할지 고민했고,
결국 Service 레이어를 넘어가지 않도록 하는 게 좋겠다고 판단했습니다.
...
해당 내용은 느낀점으론
DTO 를 통해 바로 만들 수 있는 도메인 이 있는게 아닌 이상 어쩔수 없는거 같아요.
( Entity - Domain 이 분리 되어야 한다는 뜻 )
지금 처럼 Service 단 DTO 가 생길때만 이렇게 해도 괜찮을 거 같아요.
코드 짠다구 고생했슴당 🙂
| } | ||
|
|
||
| public DevelopFeedback findDevelopFeedback(long roomId, long deliverId, String username) { | ||
| return developFeedbackRepository.findByRoomIdAndDeliverIdAndReceiverUsername(roomId, deliverId, username) |
There was a problem hiding this comment.
나중에 근본적으로 HTTP API 가 username 이 아닌 receiverId 를 받는것도 생각해봐야 겠네요
( 인덱스 지정 및 명확하게 하려면 )
There was a problem hiding this comment.
username 이 아닌 receiverId 를 받는것도 생각해봐야 겠네요
( 인덱스 지정 및 명확하게 하려면 )
👍 동의요~!
근데 memberId를 외부로 노출시키지 않기 위해 username으로 받은 설계를 했던 것 같은데, 그럼 이런 느낌으로 되는게 맞겠죠?
public class DevelopFeedbackService {
public DevelopFeedbackResponse findDevelopFeedback(long roomId, long deliverId, String username) {
// 여기서 username을 통해 memberId를 찾는다.
long receiverId = ...;
DevelopFeedback developFeedback = developFeedbackReader.findDevelopFeedback(roomId, deliverId, receiverId);
return DevelopFeedbackResponse.from(developFeedback);
}
| .stream() | ||
| .map(FeedbackResponse::fromDeliver) | ||
| .collect(Collectors.groupingBy(FeedbackResponse::roomId)); | ||
| return getUserFeedbackResponse(developFeedbackOutput, socialFeedbackOutput, room -> true); |
There was a problem hiding this comment.
해당 부분은 뭔가 뭔가긴 한대 어쩔수 없는듯요 🥲
There was a problem hiding this comment.
Reader 클래스에서 FeedbackResponse를 반환하도록 한다면 좀 편해지긴 할건데... 저 부분에선 그냥 Response 반환하자라는 유혹이 넘치더라고요ㅋㅋㅋ
방법은 더 고민해봅시당~ 👍
There was a problem hiding this comment.
Room::isNotOpened는 어떠신가영?
아래 Room::isClosed 조건이랑도 매치되는 것 같구 🤔
피드백 단계면 isNotOpened 반환값도 어차피 무조건 true일 것 같아서요.
물론 FAIL status도 통과되기는 하겠지만,
지금 로직도 OPEN이나 FAIL 단계 모두 포함하는 건 마찬가지라고 생각해용.
물론 정 FAIL인 경우가 포함되는 게 거슬린다면 isProgressOrClosed 같은 boolean 메서드를 RoomStatus에 하나 추가해도 될 것 같습니다!
There was a problem hiding this comment.
Room::isNotOpened는 어떠신가영?
생각지 못한 부분인데 좋네요~
수정 완료했습니다! 👍
jcoding-play
force-pushed
the
feat/#613
branch
from
fcd4592
to
bcbec54
Compare
이전에 조이썬이 Input, Output이란 네이밍으로 사용해본 경험이 있다고 했고, 저도 좋은 것 같아 사용하게 되었습니다. 네이밍은 서로 맞춰보면 되고, 바꾸고 쉬우니 더 나은 네이밍이 있다면 말해주시면 됩니당~ |
There was a problem hiding this comment.
안녕하세요 뽀로로~~ 리뷰가 늦어져서 죄송합니다! 😂
역시 깔끔하게 잘 작성된 것 같네요! 👍👍
수정된 점 확인했고, 간단한 제안 코멘트 몇 가지만 남겨두었습니다.
P2
저도 좋은 것 같습니다!
같은 DTO를 여기저기서 돌려쓰다보니 필요 없는 파라미터까지 전달되는 경우도 많고,
정확한 용례를 판단하기 힘들다고 느꼈던 경우도 많았거든요.
그래서 저도 RoomResponse쪽 칼질을 진행하고 있었는데
뽀로로와 같은 방식으로 mapper 한 번 활용해보겠습니다. 짱~!
| } | ||
|
|
||
| public DevelopFeedback findDevelopFeedback(long roomId, long deliverId, String username) { | ||
| return developFeedbackRepository.findByRoomIdAndDeliverIdAndReceiverUsername(roomId, deliverId, username) |
|
|
||
| private void validateUpdateAuthority(DevelopFeedback developFeedback, long deliverId) { | ||
| if (developFeedback.isNotMatchingDeliver(deliverId)) { | ||
| throw new CoreaException(ExceptionType.FEEDBACK_UPDATE_AUTHORIZATION_ERROR); |
| .stream() | ||
| .map(FeedbackResponse::fromDeliver) | ||
| .collect(Collectors.groupingBy(FeedbackResponse::roomId)); | ||
| return getUserFeedbackResponse(developFeedbackOutput, socialFeedbackOutput, room -> true); |
There was a problem hiding this comment.
Room::isNotOpened는 어떠신가영?
아래 Room::isClosed 조건이랑도 매치되는 것 같구 🤔
피드백 단계면 isNotOpened 반환값도 어차피 무조건 true일 것 같아서요.
물론 FAIL status도 통과되기는 하겠지만,
지금 로직도 OPEN이나 FAIL 단계 모두 포함하는 건 마찬가지라고 생각해용.
물론 정 FAIL인 경우가 포함되는 게 거슬린다면 isProgressOrClosed 같은 boolean 메서드를 RoomStatus에 하나 추가해도 될 것 같습니다!
There was a problem hiding this comment.
만약 위에서 room -> true를 isXXX로 바꾼다면 여기 "자신이 작성한 피드백을 받는다"
테스트 메서드 로직도 바뀌어야 합니다!
만약 비즈니스 로직을 바꾸지 않는다고 해도 현재는 OPEN 상태인 방을 테스트하고 있는 것 같아서,
CLOSED나 PROGRESS인 방을 기준으로 테스트하도록 바꾸어보아도 좋겠네요!
| @@ -43,7 +43,7 @@ class UserFeedbackServiceTest { | |||
| private SocialFeedbackRepository socialFeedbackRepository; | |||
|
|
|||
| @Test | |||
| @DisplayName("닫힌 방마다 작성한 피드백들을 구분해서 가져온다.") | |||
| @DisplayName("작성한 피드백들을 가져온다.") | |||
There was a problem hiding this comment.
여기도 마찬가지로 room3의 RoomStatus 확인해주시면 좋을 것 같아요! 👍
* [BE] 방 매칭 실패 시 매칭 실패 원인을 전달하는 기능 구현(#562) (#575) * feat: 반환된 예외를 통해 실패 원인을 찾는 기능 구현 * feat: 실패한 매칭 정보를 저장하는 엔티티 구현 * feat: 매칭을 실패했을 경우 실패한 매칭 정보를 저장하는 기능 구현 * refactor: 클래스명 변경 * feat: 반환된 예외를 통해 매칭 실패 원인에 대한 메세지를 얻는 기능 구현 * refactor: FailedMatching 생성자 변경 * feat: 매칭 실패한 방을 조회시, 실패 원인을 같이 전달하는 기능 구현 * refactor: 맵 구현체 변경 * refactor: 피드백 반영 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 방 종료 시, 코드 리뷰 완료 버튼 동작 안하도록 하는 기능 구현(#579) (#580) * feat: 방 종료 후 코드 리뷰 완료 버튼 검증 로직 구현 * fix: 잘못된 요청값 수정 (#566) Co-authored-by: youngsu5582 <[email protected]> * refactor: 리뷰 완료 요청 검증 로직 변경 --------- Co-authored-by: gyungchan Jo <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: youngsu5582 <[email protected]> * [BE] 참여했던 방이 종료되면 참여 중 탭에서 제거(#581) (#584) * feat: 참여했던 방이 종료되면 참여 중 탭에서 제거하는 기능 구현 * [BE] 중복으로 매칭되던 상황 해결(#587) (#588) * refactor: 도메인 수정 * feat: 리뷰어, 리뷰이 조회 API 기능 구현 * refactor: 중복된 기능 코드 제거 * docs: 메서드 시그니쳐 통일 * feat: 시연용 데이터 추가 * refactor: 패키지 이동으로 인한 오류 수정 * feat: 시연용 데이터 추가 * fix: REMOTE_ORIGIN 그냥 변수로 변경 * feat: 데이터 추가 * feat: 서브모듈 반영 * feat: response 생성 때 reviewer, reviewee 분리 * feat: application 설정 변경 * feat: 데모 데이터 함수로 분리 * fix: 누락된 saveAll 추가 * fix: 데이터 정합성 수정 * fix: roomId 상수 변경 * feat: 피드백 키워드 뒤 .제거 * refactor: 3차 데모데이 데이터 변경 * feat: room 4에 대한 케이스도 추가 * feat: room 4 매칭 추가 * fix: 응답 내 프로필 링크로 변경 * 최신 브랜치 병합 * feat: submodule 업데이트 * refactor: 서브모듈 변경 * fix: 매칭 중복 예외 처리 안되던 오류 해결 * fix: 리뷰어 매칭 안되던 오류 수정 * test: participationFilter 로직 수정에 따른 테스트 수정 --------- Co-authored-by: hjk0761 <[email protected]> Co-authored-by: youngsu5582 <[email protected]> * feat: pr 제출 안 했을 때 문구 추가 (#590) Co-authored-by: jinsil <[email protected]> * [BE] 방 생성 검증 로직 주석 처리(#593) (#594) * refactor: 방 생성 검증 로직 주석 처리 * refactor: 운영 환경 설정 변경 * refactor: 방 생성 검증 로직 테스트 disabled 처리 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 방 매칭 실패 시 매칭 실패 원인을 전달하는 기능 구현(#562) (#575) * feat: 반환된 예외를 통해 실패 원인을 찾는 기능 구현 * feat: 실패한 매칭 정보를 저장하는 엔티티 구현 * feat: 매칭을 실패했을 경우 실패한 매칭 정보를 저장하는 기능 구현 * refactor: 클래스명 변경 * feat: 반환된 예외를 통해 매칭 실패 원인에 대한 메세지를 얻는 기능 구현 * refactor: FailedMatching 생성자 변경 * feat: 매칭 실패한 방을 조회시, 실패 원인을 같이 전달하는 기능 구현 * refactor: 맵 구현체 변경 * refactor: 피드백 반영 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 방 종료 시, 코드 리뷰 완료 버튼 동작 안하도록 하는 기능 구현(#579) (#580) * feat: 방 종료 후 코드 리뷰 완료 버튼 검증 로직 구현 * fix: 잘못된 요청값 수정 (#566) Co-authored-by: youngsu5582 <[email protected]> * refactor: 리뷰 완료 요청 검증 로직 변경 --------- Co-authored-by: gyungchan Jo <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: youngsu5582 <[email protected]> --------- Co-authored-by: gyungchan Jo <[email protected]> Co-authored-by: ashsty <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: hjk0761 <[email protected]> Co-authored-by: youngsu5582 <[email protected]> Co-authored-by: jinsil <[email protected]> * refactor: 로컬 서버용 깃허브 토큰 변경 (#600) Co-authored-by: gyungchan Jo <[email protected]> * [BE] Room Controller 역할 분리(#595) (#596) * refactor: Room Controller 역할 분리 * refactor: 피드백 반영 --------- Co-authored-by: youngsu5582 <[email protected]> * [BE] 자동 예약 및 자동 업데이트 동시성 제어(#586) (#604) * feat: Lock을 통한 자동 매칭 동시성 제어 기능 구현 * feat: Lock을 통한 자동 업데이트 동시성 제어 기능 구현 * feat: 자동 매칭 Lock 범위 최소화를 위한 클래스 구현 * feat: 자동 예약 Lock 범위 최소화를 위한 클래스 구현 * test: 자동 매칭 테스트 중복 코드 추상 클래스로 이동 * test: 자동 예약 테스트 중복 코드 추상 클래스로 이동 * refactor: Transactional 어노테이션 제거 * refactor: 피드백 반영 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 방 수정 기능 & 스케줄러 부분 분리 및 리팩토링(#605) (#606) * feat: repository 의존성 제거, 테스트 명확하게 변경 * feat: Reader/Writer 통해 조회 로직 분리 * feat: 룸 수정 기능 구현 * refactor: 피드백 반영 * fix: 충돌 해결 --------- Co-authored-by: youngsu5582 <[email protected]> * [FE] 콜리네 서비스 제공후 QA(#597) (#602) * fix: 모집 마감 -> 종료된 방으로 변경 * fix: 매칭 후 pr 제출 안 해서 실패했을 때 바로 문구 띄우기 * design: 모달 이름에 width 변경 * design: 프로필 드롭다운에서 이름 다 보여지게 하기 * design: 배너 medium일 때 높이 수정 * feat: timeDropdown에서 선택된 시간이 제일 위에 떠있게 하기 * feat: 피드백 모아보기에서 세부 피드백에 scroll 추가 * design: 세부 피드백 높이 지정 * fix: content 길이 길어졌을 때 ... 로 보이게 하기 * design: 피드백 모달 엔터처리, line-height 추가 * feat: 분류 드롭다운으로 선택하게 변경 * feat: 키워드 없을 때 ui 처리 * feat: 방 매칭 실패 시 서버가 준 message 띄우기 * [BE] Room Controller 역할 분리(#595) (#596) * refactor: Room Controller 역할 분리 * refactor: 피드백 반영 --------- Co-authored-by: youngsu5582 <[email protected]> * refactor: ALL 타입 추가 * feat: 수정된 api에 맞게 message 타입 추가 * fix: 방 생성 시 키워드 입력을 안했을 때 렌더링 조건 수정 * feat: 바뀐 RoomInfo 데이터 형식에 맞게 storybook 수정 --------- Co-authored-by: jinsil <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: youngsu5582 <[email protected]> Co-authored-by: 00kang <[email protected]> * [BE] 참여했던 방이 종료 된 후, 종료 탭 및 마이페이지에서 안보이는 문제 해결(#607) (#611) * refactor: 참여한 방을 조회하는 기능 수정 * refactor: 방을 조회하는 기능 메서드 분리 * refactor: 방을 조회 메서드 클래스 분리 * test: Nested 어노테이션을 통한 RoomServiceTest 관심사 분리 * feat: 참여했던 방이 종료되면 종료 탭에서 보이도록 하는 기능 구현 * feat: 종료 탭에서 자신이 참여했던 방도 나타내는 기능 구현 * test: 테스트 수정 * refactor: 조회 쿼리 수정 * refactor: 피드백 반영 * refactor: 변수명 변경 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 로그 중복 작성 제거, 비즈니스 로직 내 로그 추가(#608) (#610) * feat: additivity false 로 변경 * refactor: 참가,취소 로직 분리 * chore: 로그 레벨 변경 * feat: 로그 추가 * refactor: 피드백 반영 --------- Co-authored-by: youngsu5582 <[email protected]> * [FE] 24시간 이하로 남으면 디데이 말고 시간 보여주기(#598) (#609) * fix: 디데이가 1일 남은경우에도 24시간 미만 남은경우 남은 dday로 반환하도록 변경 * refactor: areDatesEqual 함수를 dateFormatter 유틸 함수로 이동 * fix: 중복된 함수 제거 * test: 데이터 포메팅 유틸 함수 테스트코드 추가 * test: 테스트 시 이미지 모듈은 mock string 값이 반환되도록 모킹 * test: 룸 카드의 남은 기간 정보 UI 렌더링 테스트 추가 * fix: 진행중인 방의 D-Day 가 잘못 표기되는 문제 해결 * test: 테스트 명세 오타 수정 * test: 방 상세정보의 모집/리뷰 마감까지 남은 시간 렌더링 테스트 추가 * test: jest 환경에서 시간대를 한국 시간대를 사용하도록 변경 * feat: SEO 최적화를 위해 html에 메타태그 추가 --------- Co-authored-by: Lee sang Yeop <[email protected]> * [FE] 생성페이지 달력, 시간 입력 리팩토링(#603) (#614) * design: 방 생성 페이지 모바일, 태블릿 대응 * refactor: error props 제거 * feat: DateTimePicker 생성하여 날짜, 시간 한번에 관리 * refactor: formatCombinedDateTime 인자 하나로 받기 * refactor: handleInputChange 함수로 통합하기 * refactor: 분류 type 맞추기 * feat: 방 생성 유효성 처리 --------- Co-authored-by: jinsil <[email protected]> * refactor: 초기 데이터 주석 처리 * refactor: 초기 참여자 사이즈 변경 * feat: 매칭 실패 원인을 전달하는 기능 구현 * [BE] 방 응답 시, CLASSIFICATION 반환 추가(#621) (#623) * feat: 방 정보 응답 시, classification 정보 추가 * feat: 개발 서버 액세스 토큰 변경 * test: 테스트 통과하도록 주석 처리 --------- Co-authored-by: gyungchan Jo <[email protected]> * refactor: 요청 dto 제약 조건 변경 * [FE] 방 수정 기능 추가(#616) (#620) * feat: hostType node_env로 판별 * feat: 검색 title 변경 * fix: test에 message 추가하여 오류 해결 * feat: 방 수정 api 추가 * refactor: classification 속성 추가하기 * refactor: 방 상세 정보 가져오는 함수 훅으로 분리 * feat: 방 생성, 수정 페이지 분리 * fix: put 요청으로 변경 * refactor: getInitialFormState 함수로 분리 * design: 드롭다운 선택된 것 다르게 보여주기 * refactor: 불필요한 코드 제거 * fix: roomId로 변경 * feat: roomId로 변경 --------- Co-authored-by: jinsil <[email protected]> * [FE] 참여 중인 방에 대해 바뀐 명세서 반영하기(#612) (#622) * refactor: 수정된 API명세서에 맞게 includeClosed 쿼리 추가 * feat: 참여중 라벨 추가 * feat: 참여중, 모집중 라벨 같이 보여주기 * feat: 종료, 매칭실패 라벨 같이 보여주기 * feat: 참여중 라벨을 범용적으로 사용하기 위해 참여로 수정 * refactor: 참여 라벨, 매칭실패 라벨 고려하여 추가하기 * test: roomStatus, participationStatus, message 상태에 따라 다르게 보여지는 라벨의 테스트 구현 * feat: 서비스 어느 곳에서든지 참여 라벨이 있을 경우 상세페이지로 리다이렉팅 --------- Co-authored-by: 00kang <[email protected]> Co-authored-by: Lee sang Yeop <[email protected]> * [BE] 쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 변경 + 리팩터링(#613) (#617) * refactor: 작성한 피드백은 바로 피드백 모아보기에서 보도록 수정 * refactor: 피드백 가져오는 역할 클래스 분리 * refactor: 개발 피드백 작성 기능 수정 * refactor: 개발 피드백 수정 기능 변경 * refactor: 개발 피드백 조회 기능 수정 * refactor: 생성, 수정 dto 분리 * refactor: 피드백을 조회하는 기능 수정 * refactor: 피드백 반영 * refactor: 피드백 반영 --------- Co-authored-by: gyungchan Jo <[email protected]> * [BE] 매칭 로직 원복 및 수정(#624) (#627) * refactor: 도메인 수정 * feat: 리뷰어, 리뷰이 조회 API 기능 구현 * refactor: 중복된 기능 코드 제거 * docs: 메서드 시그니쳐 통일 * feat: 시연용 데이터 추가 * refactor: 패키지 이동으로 인한 오류 수정 * feat: 시연용 데이터 추가 * fix: REMOTE_ORIGIN 그냥 변수로 변경 * feat: 데이터 추가 * feat: 서브모듈 반영 * feat: response 생성 때 reviewer, reviewee 분리 * feat: application 설정 변경 * feat: 데모 데이터 함수로 분리 * fix: 누락된 saveAll 추가 * fix: 데이터 정합성 수정 * fix: roomId 상수 변경 * feat: 피드백 키워드 뒤 .제거 * refactor: 3차 데모데이 데이터 변경 * feat: room 4에 대한 케이스도 추가 * feat: room 4 매칭 추가 * fix: 응답 내 프로필 링크로 변경 * 최신 브랜치 병합 * feat: submodule 업데이트 * refactor: 서브모듈 변경 * feat: submodule 업데이트 * refactor: 매칭 로직 원복 * fix: 매칭 로직 오류 수정 * refactor: 변수명 직관적으로 수정 * refactor: 리뷰어를 제외하고 matchingSize 만큼 추가 매칭하도록 수정 * refactor: 리뷰어가 matchingSize 만큼 리뷰이와 매칭되도록 수정 * feat: submodule 업데이트 * refactor: 피드백 반영 * refactor: 변수명 수정 --------- Co-authored-by: hjk0761 <[email protected]> Co-authored-by: youngsu5582 <[email protected]> Co-authored-by: HyunJoong Kim <[email protected]> * [BE] 참여한 전체 방들 조회할 때, 실패 원인 같이 보내는 기능 구현(#625) (#629) * refactor: ParticipationWriter 패키지 변경 및 코드 포맷팅 적용 * refactor: 작은 단위로 클래스 분리 * refactor: 예외 타입명 변경 * refactor: 참여했지만 매칭에 실패했던 모든 방들을 조회할 때 실패 메시지를 같이 보내는 기능 구현 * refactor: 방 조회 기능 수정 * test: 방 관련 테스트 추가 --------- Co-authored-by: gyungchan Jo <[email protected]> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: gyungchan Jo <[email protected]> Co-authored-by: youngsu5582 <[email protected]> Co-authored-by: ashsty <[email protected]> Co-authored-by: hjk0761 <[email protected]> Co-authored-by: jinsil <[email protected]> Co-authored-by: 00kang <[email protected]> Co-authored-by: HyunJoong Kim <[email protected]>
📌 관련 이슈
✨ PR 세부 내용
쓴 피드백은 피드백 모아보기에서 바로 볼 수 있도록 수정하였습니다.
그리고 피드백 서비스 쪽에 대한 리팩터링 범위가 그리 크지 않을줄 알고 같이 작업을 했었는데,
생각보다 범위가 커서 일단 현재 작업한 부분까지만 PR 제출하고 나머지 피드백 서비스쪽 리팩터링 이어서 해볼게요.
현재 파일 변경 범위가 넓어 "쓴 피드백은 피드백 모아보기에서 바로 보기 기능"에 대한 변경 사항만 보고 싶으시다면
쓴 피드백 조회 기능 수정 여기를 통해 봐주세요.
P2: DTO 관리
Reader와 Writer의 역할을 분리하면서 RequestDto와 ResponseDto를 어디까지 전달할지 고민했고,
결국 Service 레이어를 넘어가지 않도록 하는 게 좋겠다고 판단했습니다.
그래서 어제 조이썬과 논의한 결과, Service와 Domain 간의 데이터 전송을 위해
RequestDto는 InputDto로, ResponseDto는 OutputDto로 변환하기로 했습니다.
그래서 각 DTO를 변환하는 작업이 필요했는데, 제가 구현한 방식은, 각 레이어의 DTO가 다른 레이어의 DTO에 의존하지 않도록
Mapper 클래스를 만들어 변환 작업을 관리하도록 했습니다.
이런 구조를 통해 특정 레이어의 DTO가 다른 레이어의 DTO에 의존하지 않도록 분리하려는 것이 목적이였습니다. 만약 서로 다른 레이어의 DTO가 의존하게 된다면, 작업은 편리해질 수 있지만, 레이어 간 의존성이 생겨 복잡도가 높아질 수 있다고 생각했습니다.
하지만 애기 나눠보고 싶은 점은 이런 방식이 유지보수와 확장성 측면에서 정말 최선인지 궁금합니다.
혹은 DTO 간 어느 정도의 의존성을 허용하여 개발 편의성을 높이는 방안도 고려할 수 있을 것 같은데, 다들 어떻게 생각하시나요?
Mapper 클래스를 이용한 관리 방식이 좋은지, 아니면 다른 대안이 있을지 자유롭게 의견을 나눠주시면 좋겠습니다!